Just How Difficult Is SAP to Implement? 

A Detailed Look at SAP Project Management 

By Tomas Fertig, BDO Consulting 

Editor's Note: Let's face it: most articles on ERP project management aren't worth the paper 
they're written on. How many times can we read bland cliches like “if you don't plan ahead, your 
project will fail?” Of course, we all recognize the importance of strategic planning. But how do we 
really determine a successful project approach from an unsuccessful one ? With this edition of 
SAPtips, we're delighted to present a brilliant article on SAP ® Project Management that digs deep 
into SAP and goes well beyond the standard pretty-sounding advice. Why does this article work? 
We think it's because the author, Tomas Fertig, has worked his way up from hands-on SAP 
consultant to Practice Manager. Tomas has tasted project successes and failures firsthand, and 
his passion for SAP keeps him on top of the latest technologies. This twenty-page guide is filled 
with sharp insights on the best ways to approach SAP projects and the missteps to avoid. Tomas 
covers everything from the importance of business model definition to the need for a thoughtful 
approach to cultural change management and employee compensation. Tomas explains why a 
good “solutions map” is so important, and throughout the article, he connects project leadership 
concepts with the SAP tools and technologies that can make implementations more successful. 
Tomas ends the paper with a series of comments on the latest SAP technologies users should be 
staying on top of, and his opinionated appendix on the different types of SAP consultants is 
provocative and useful reading. Tomas has told us that he will follow up this paper with some 
discussions of specific project management issues, and he welcomes reader input on future 
topics to address. 

There are common myths and prejudices in the market about implementing SAP. Such systems 
are believed to be too complex, too difficult to implement and maintain, with long and costly 
projects affordable only for big corporations 1 . As an ERP consultant, I could have chosen other 
systems, but I am convinced that SAP provides the most complete solutions and that it is possible 
to implement them easily, in a simple way, and within any budget range (with obvious differences 
in scope and methodology). I am in no way economically tied to SAP: I am just honestly 
convinced from a technical point of view and eager to share my experience and my knowledge. 

In terms of my own SAP background, I am certified in MM, ASAP, ABAP, and Workflow and have 
broad experience in the integration of many different modules and solutions within the SAP 
environment. I have participated on SAP projects as a programmer, consultant, leader, quality 
assurance specialist, and solution developer. On different projects, I have been the person 
responsible for managing new implementations, migrations, improvements, roll-outs, model 
definitions, training, and archiving. 

What follows is my view on why fears about difficulties implementing SAP 2 are common in the 
market, how SAP is changing this, and what you should take into account for a cost-effective and 
successful SAP implementation. In this article, I will also cover the success factors and common 
mistakes that companies make while installing and running on SAP. This analysis is not only 
directed to the initial implementation, but covers all stages of a business solution lifecycle: 



1 There are a couple of interesting official SAP articles stating the six myths about SAP. I am not 
going to quote them here because they are mainly directed to small and midsize business. This 
article is addressed to all the stages of SAP Project Management (from a solution map, 
implementation itself, and rollouts, to maintenance and the implementation of new functionality) 
for companies of all sizes. 

2 SAP is offering a new integrated product for smaller companies: SAP Business One. This article 
does not including any reference to this product nor how to implement it, although most of the 
principles in this article should also apply to it. 
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implementation of a long-term solution map, the implementation itself, maintenance, migrations, 
new functionality enhancements, etc. 


SAP Business One 


Smaller sophisticated SMB companies 


mySAP-AII-ln-One 


SMB companies with complex processes 


mySAP Business Suite 


Big companies and corporations 


Success Factors for a Long-Term SAP Solution 

The Key to User Acceptance: A Good Information Policy 

SAP Solutions deeply affect the culture and the working environment of the people in a company. 
Even after you get through “go live” and enter production, it is a major change. What is going to 
happen and how it is going to happen must be clearly defined and publicized from the top 
management downwards. SAP implementations need to involve a lot of people and the right 
information should be known by the implementation and maintenance teams. If the top 
management does not do this, how do you think people will react? They will likely resist the 
changes SAP requires of them, and this will affect the quality of SAP Solutions. 

There are also lots of myths and implicit messages when you implement an SAP solution that can 
affect the morale of the company as a whole. In the past, many companies implemented SAP to 
reduce personnel and costs, and this is still a fear every time SAP solutions are implemented, 
even though nowadays such reductions are not the main reason for choosing SAP solutions. 
Today the main reasons are profitability, efficiency, control, better information, and more time for 
people to generate value. Obviously there are sometimes chances to cut costs and personnel, 
and these are also big issues, but it is very important to preserve the right people and to maintain 
them in the right state of mind. Therefore, it is a major success factor, during the implementation 
of SAP Systems, to keep everyone informed in the right way, even people who are not directly 
involved in the process. It is surely true that with SAP solutions many positions and jobs are going 
to change and many activities will either disappear or the way they were being done will change. 

If the relevant people in the company perceive these changes without any information about 
eventual relocation or what is expected from them after the installation process, these people will 
probably begin to look for new horizons at other employers. 

Another issue is the internal project team. It is well known that the result of an implementation 
project is better if you use your best employees as the key users and implementation team 
members: you need to select those who are always busy and short of time, those with the best 
knowledge of the past, present, and future of the organization. This means they will need some 
help during the project to complete their usual jobs, or else they will have to work much more than 
usual. If you do not inform them about how the company is going to handle these issues and the 
reinsertion into their old jobs after the project, it is only a matter of time before these people will 
begin to think about their future in the company. I have seen many cases of companies that have 
lost important collaborators after an implementation. This can and should be avoided. 
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A good information policy minimizes all these risks. Normally it is very important to include the 
Human Resource departments in all decisions around SAP solutions; because these issues affect 
people, the HR department can play an important role here. Change management during the 
entire process is an everyday issue. Even if someone thinks there are companies that do not 
need to plan for change or that companies are mature enough, well, I must say these things 
happen every time. And it is not very difficult to deal with these things in advance. 

Properly Defining SAP Functions and Roles 

There are different functions to be covered during projects, maintenance, rollouts, and in general 
during operation of SAP solutions. One of the most important success factors is to choose the 
right profiles and people for the right functions. In this section, I am going to summarize some 
typical mistakes and best approaches to the handling of SAP functions and roles. 


Pre-Project SAP Solution Implementation 


SAP-Operation 


m 








Project Business 
Preparation Blueprint 


Realization 


Final 

Preparation 


Go-Live 

& 

Support 


• Definition of solution map: This is clearly a function that must be performed by the high- 
level management of the company with the help of the CIO and perhaps a high-level external 
consultant. Even though a solution map is in a permanent state of change depending on the 
company's evolving business plans, it must be prepared before the selection of an SAP 
environment or any other world-class solution. For companies that choose the SAP 
environment, it is useful to include the SAP account manager and perhaps a high level SAP 
pre-sales consultant in the creation of the solution map. These SAP employees can help 
chart out the possibilities, but it must be taken into account that they are selling software. A 
good solution map defines the actual IT solutions landscape, and spells out a short-term and 
a long-term structure, taking into account the business plan for the company. The technical 
stages to get to the future landscape should also be part of this plan, along with a budget for 
each stage. Today nearly all of a company's business plans are somehow related to tools 
and IT solutions. 

• Sponsorship: In every successful SAP project, there are one or more sponsors. The 
sponsors are selected by the people paying for SAP; they are the people making the 
decisions and those who expect the most from it. They are always named in the project team 
organization and their function is to make key decisions about resources and strategic issues 
for SAP solutions. I have seen several cases where the decision to implement SAP was 
made, and a sponsor was named solely because of the influence this person had on the 
decision itself, not because he or she was the most influential person in the organization. This 
can be the wrong message to send. The name of the sponsor(s) of the SAP project team is a 
message. Ideally, the sponsor should be the most influential person in the company (the 
owner, the general manager, the founder, the strongest member of the family or the board of 
directors) in order to give a clear message that SAP solutions are a central part of the future. 

If the sponsor cannot represent the whole organization, and isn't respected by the different 
constituencies in the company, then this can be a quality risk and a message for some 
important employees to not participate in the project. 
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• Leadership: There is always an operative leader from the company side for the 
implementation and maintenance of SAP Solutions. The technical ability to perform this 
function is relatively easy to locate. The most important ability to succeed in this job is not 
that easy to find. This position should be covered by a respected member of the company 
who can influence and mediate when discrepancies appear, someone who can make 
decisions that will be respected and who knows the culture and business of the company. 

You can hire an external CIO or external technicians, but the project leader hired externally 
will have a very difficult job and can fail for lack of knowledge about the business or because 
his or her decisions are not respected. 

In projects with consultants, there is also always a leader from the consulting side. This 
leader should have technical, communication, mediation, and methodology abilities. 

Obviously it is better if he or she has vertical industry experience, but in my experience these 
characteristics are not as important as the previous ones. At this level, a lack of vertical 
experience can be compensated for by a good “listening” ability, common sense, and general 
business experience and knowledge. But having said that, the best SAP consulting leaders 
are generally leaders with SAP consulting knowledge, that is, leaders who progressed from 
early roles as “SAP Business Consultants” into project leaders. If there is a chance to 
choose, it is better to choose a consulting leader from the most relevant area for your 
company (production, costs, delivery, commercial, financial, etc.). 

• Business Model Definition: The business model definition is a matter for the best people in 
the company. Those with the best knowledge of the company's history, its core processes, 
and how the business is positioning itself for the future should be selected. The best models I 
have seen are those developed by really engaged employees with a long career in the 
company, assisted by good “SAP Business Consultants.” These consultants bring in not only 
the technical knowledge of SAP solutions, but also a good knowledge of business process 
and module/product integration. In my experience, the worst business models were almost 
always defined by external people with only the assistance of outside technicians or “SAP 
Implementors.” (In the Appendix to this article, I will define some of these outside SAP 
consulting roles in a bit more detail.) 

• Change Management: As we've noted, during the development and maintenance of SAP 
solutions, there are several functions, positions, and ways of doing things in the company that 
will necessarily change. The administration of these changes is not always done in a 
conscious way, but such changes occur every time, no matter how mature your organization 
is. You can have the internal and consulting leaders together with the HR department 
manage these changes, or you can assign a specific person within the company for the 
administration of this issue. In my experience, the best change management teams are 
comprised of external consultants AND internal employees. External consultants have 
already helped other users through an adjustment to SAP, and your internal employees have 
insights into your unique work environment that an outside consultant must know in order to 
carry out a successful change management strategy. The bigger the project and 
organization, the more important it is to make this activity a full time focus for one or more 
employees. 

• Information and publications: Every goal, news and steps of the project should be 
distributed to the whole organization. A good information policy ensures that people will help 
the project team as much as possible to achieve a successful implementation, and it prevents 
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people from thinking that they could be obsolete after the SAP solutions goes live. This 
should be done by the HR department or someone whose job relates to communications. 

• Administrative issues: There are many administrative issues to be dealt with during an SAP 
project. It is really not important who does this, but it is important that it be done. There are 
some activities that should be done by everyone, and it is important that they be done as 
close to real time as possible, such as making and distributing memos of all the meetings. 
This documentation is important because in an SAP project, nearly all of these memos define 
future activities (especially at the beginning of the project) and all decisions made should be 
explained to all participants. The best method I have seen is to designate one person as 
responsible for memo compilation during the meeting and then after the memo is distributed 
to all participants, 24 hours of non-complaint implies acceptance of the content. This policy 
avoids time delays and prevents activities from having to be continuously readjusted. The 
fulfillment of this policy is the responsibility of the project managers. 

• Customizing/Parameters: A good technical solution is also a part of the success of an SAP 
implementation. Key technical decisions must be made, such as: how much are we going to 
customize SAP to fit our business model, and what parts of the software suite will we install? 
The best people to handle this function are the “SAP Implementors” (as I defined at the end 
of this white paper). However, depending on your knowledge-transfer philosophy, the size of 
the project, and your general policy with consultants, this function can also be covered by 
internal people with the support of consultants (the best way for a good knowledge transfer) 
or by an “SAP Business Consultant.” (Please refer to the types of consultants in the Appendix 
of this article.) 

• Documentation: There are lots of tools and methodologies for documenting SAP during a 
project. There are also lots of different documents that can be generated: BBP (Business 
Blue Print - “As Is” and “To Be”), Configuration guide, End User Manual, Project Plan, 
Solutions Map, etc. One thing is certain: the more documentation you generate, the more 
people you need to maintain it in order to avoid letting the documents become dated and 
useless. Both extremes are very dangerous: having no documentation makes you really 
dependent on consultants and on your own people who participated in the project; too much 
documentation gets old too quick and you then have the same problem, or you need too 
many people to maintain it. Therefore, documentation is very important, but you do not need 
a very high level of expertise to do it. You can probably do it just with internal resources for 
smaller projects. Only big projects justify contracting consultants (mainly junior consultants) to 
do this. My experience is that if you cannot maintain documentation of everything, then you 
should concentrate on maintaining the “big picture” documentation of the model and updating 
the relevant changes to the end-user manuals. I have seen companies of all sizes 
complaining that they have a lot of documentation, but most of it is as old as the initial project. 

• End-User Training: My experience tells me the best people to train the final users are those 
who are going to maintain the system and operate the internal help desk. (The student 
always asks the teacher, and if the teacher is the consultant, he is not always going to be 
there.) How you meet this need depends on your knowledge-transfer philosophy and the 
general policy about consultants. As a rule, it is better that the internal people give the 
training, assisted by the consultants. 

• Knowledge transfer: I will get into this issue in more detail in the next section of this paper. 
But for now, note that knowledge management is not about the end-user training, but about 
the knowledge transfer to the internal SAP team in charge of maintaining the system. For this 
activity, it is important to know who is going to receive the knowledge transfer and what kind 
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of consultants are best prepared for this activity. Whether someone in the organization is 
going to receive the knowledge transfer and who exactly is going to receive it depends on 
your policy about maintenance. If the company wants to be as independent as possible of 
consultants, it should select people who are surely going to stay and who want to receive 
such knowledge. There should also be a commitment to compensation increases for them, as 
they will know that they are going to become more important to the company. 

The best way to transfer knowledge is to make sure that those receiving it are participating as 
actively as possible in the project definitions, the customizing, and that they eventually 
become the instructors in the end-user training As for your internal team, those who are 
selected for knowledge transfer should use SAP in their day-to-day jobs. A little formal 
training with SAP courses is important, but it's useless if people do not participate in daily 
SAP tasks. I have seen many projects where the internal team takes a lot of SAP courses 
and then is used only for basic documentation and data transfer tasks. . This is a lot of money 
spent without a real benefit to either the user or the company. If the employee can't put the 
training to work on the job, it will become stale. 

• Technical issues: Despite the warnings you might hear on never making changes to the 
standard code, in every project you will need programmers and technical staff for SAP 
installation, database administration, the transportation of system changes, development of 
reports and interfaces, and adaptation of all forms to the company's needs. Note that, 
whereas it is important who is in charge of these technical issues (and there are good 
technicians in the market these days), it is even more important who defines the jobs to be 
done. 

On many SAP projects, there are a couple of common mistakes that make people think you 
will need lots of programmers on an SAP project. The higher the seniority your consultants 
have, and the closer to “SAP Business Consultants” they are, the fewer programmers you will 
need to solve problems and the fewer custom developments you will need, because you will 
anticipate the issues in the design phase and find ways of adapting to SAP's functionality 
without alteration. Programmers are also very pleased to have good definitions of 
developments and reports; this is better done by people who understand the business as well 
as the solutions. 

• End-Users Help Desk: you will need a help desk after going live. End-users will have 
questions and continuous needs for improvements and these needs should be administered. 
These issues can be dealt with by specialized people outside of your implementation team, or 
by the internal team directly. Best practices suggest that someone with a basic knowledge of 
the system and the business model should filter these help desk inquiries. This also permits 
the help desk person to understand the new needs and solve them by applying an intelligent 
and global solution. The important thing is to understand help questions not as a task list of 
one-time problems, but as a list to be compiled to search for iterative problems, incongruent 
results, and important user needs. I have seen several different tools for taking care of help 
desks, from simple spreadsheets to internally-developed tools to complex vertical systems. It 
is not a matter of the tool, but of how you use it to improve your SAP solution. It is a 
responsibility of the management to understand this and to make it happen. 

• Model improvement: This activity is a result of the analysis of the company’s needs or the 
users’ issues, as shown through the help desk tickets. The best policy for this issue is to 
understand the needs and always try to solve them in the short term within the model, trying 
to generate a future improvement list. It is a mistake to continuously make changes to the 
customizing and continuously add reports and developments to the SAP solutions. If this 
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happens, it can be the result of a couple of deeper problems: a bad definition of the model 
and/or a bad culture about information: “I need it my way or in the usual way and not in the 
company's or best practices way.” 

• Testing and approval: This task refers to the final obstacle before entering production with 
SAP solutions. In any stage of SAP, either during the actual implementation or during 
improvements or changes to the model, the system should be tested and approved by 
different people (for example end users or key users) than those who develop or customize 
them. I have seen too many SAP implementations where the testing is done by the same 
consultants or members of the internal team who define and produce the changes with 
obvious problems. This is basic for any controller of any process. The one who uses the 
system daily should not be the one who tests and approves them. The same applies to SAP 
solutions. As SAP users know, there are very good tools to administer approval processes in 
the SAP landscape for transportation of program and customizing changes. The only problem 
is that the approval process and tools are not always well used: it is sometimes seen as 
easier to bypass the process and release the changes faster. But this can lead to problems 
down the line, so there should really be no shortcuts in the vital testing and approval phase. . 

• Data transfer: Just before entering production or during live operation when the solutions 
landscape includes other systems, there is a lot of data that must be transferred into the SAP 
solutions. There are many different methods and tools to transfer data, and I'm not going to 
get into all of them now. The thing I want to mention at this point is about data transfer 
responsibilities. There are two kind of responsibilities related to this issue: 

♦ the technical responsibility to enter or transfer data into the SAP 
system at the right time and in the right way; 

♦ and the functional responsibility to ensure the integrity and rightness 
of the data. 

These two responsibilities are not always assigned to the same person, and it is obvious that 
the first task is more a technical issue and the second more related to the ultimate users of 
the system. In my experience, the best results appear when the interfaces developed are so 
easy to use that one final user can handle both tasks without help. This leaves the whole 
responsibility to one person and avoids discussions about who made mistakes, should they 
appear. 

This was not intended to be an exhaustive list of all functions, activities, and roles in all types of 
projects. There are surely other important roles and activities in special types of projects like 
migrations or rollouts. I am preparing special articles on these types of SAP projects in order to 
share my experience on these specific issues. 

Defining Your Future Business Model 

A good strategy for where you want to be in the future is crucial for SAP solutions. There are lots 
of definitions that limit the possibility of future utilization of new functionality. Therefore, if you do 
not hire “SAP Business Consultants” to help you define your model, taking into account not only 
the present phase but also the future ones, you will surely pay for this down the line. This is the 
most important issue and the key success factor for any SAP implementation. Everyone on the 
project must understand that the company that implements SAP is the owner of the business 
model. (Despite what anyone might say, no consultant is.) And despite what some consultants 
might say, the company is the one that knows the business better than anyone else. (A 
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consultant makes a mistake if he sees himself as anything more than a facilitator). The 
consultants are there to help the company with their experience and knowledge of the SAP 
product line. The better the consultants’ experiences in the user’s vertical market, the better the 
consultants can help define the present and future business model for all stages of the SAP 
solutions implementations, improvements, and maintenance. 

The information technology tools that will be used to support the future business model of the 
company are defined in the solution map. (I have already mentioned some important points about 
this earlier in the paper.) It is important to make this map as clear as possible, even if it is not 
certain what kind of solutions the company will need in the future to go with the company’s 
business objectives. The solutions map normally has two points of view: a process point of view 
where the needs are globally defined in a timeframe, and a technical point of view where the 
possible tools, modules, products, and solutions are defined. 

I have seen too many examples where some SAP functionality was installed without considering 
the big picture and future needs, and later, this limited the implementation of new 
modules/functionalities. To make this clear, I want to bring in a real example: 

• A company decided to implement SAP R/3 with the following modules: FI-CO-MM-SD 

(accounting, treasury, costs, sales, stocks and purchasing). They defined the model and did 
the customizing, thinking only of this scope. After a couple of years, they wanted to expand 
the solution to include the PP (production planning) module and realized that definitions 
made on the material master data during the first stage were incongruent with the needs for 
the production procedures. They realized the effort to change the whole model was really 
expensive and decided not to implement the module. Therefore, the mistake, made at the 
beginning because the original implementation team did not take into account the big picture 
of the planned solution map, came back to haunt them later. 

As you see in this example, it is important that the solution map include all the possible future 
situations that can happen. The best examples I have seen detail not only the current situations, 
but also take into account the current needs that are not covered because of budget limitations. 
The best maps also take into account the future needs that can emerge because of the 
company’s business objectives and the eventual needs that can emerge because of unplanned 
situations (recognized because of the experience of the people who developed the solution map). 

Because of my experience, I am often asked to analyze the available solution map to be sure the 
company is taking into account the best available tools and solutions. In these cases, my goal is 
to take full advantage of the current and emerging SAP technologies, and this can be a 
challenge. SAP evolves so quickly that even SAP cannot entirely predict its own future. Being that 
SAP is the market leader, SAP users have a good view of the future with the SAP environment, 
but a good practice is to periodically review the solution map taking into account any new 
business situations and the new tools, products, and technology trends in SAP solutions. 

The solution map is not just a strategic document for the management. It should also be 
distributed to all maintenance team members and consultants participating in any activities 
around the SAP solutions, as the definitions made there can affect many activities currently being 
performed. Unfortunately, this does not happen very often. What I have seen is that solution 
maps are not a very well known document on most SAP projects. They are not generally very 
well distributed. 



Copyright © 2004 by Klee Associates, Inc. 

www.SAPtips.com 


Page 8 



Just How Difficult Is SAP to Implement? 

A Detailed Look at SAP Project Management 



Best Practices and Micro-Vertical Solutions 

A few years ago (around 1 999), SAP began to speak about solutions and no longer about 
systems and applications. It was not only a commercial and marketing initiative; it was and is a 
new philosophy: to understand the problems in a vertical way and bring solutions to their 
customers — independent from the actual tools or applications to be used. At this point, best 
practices began to be more important, as SAP tried to provide sound methodologies that worked 
across a range of implementations. Many tools appeared to sustain this new philosophy and tried 
to compile all the knowledge of thousands of implementations worldwide. At the beginning, these 
tools were mainly documentation. But today there are lots of best practices, across many SAP 
and mySAP® solutions (like the best practice model for CRM) and vertical guidelines (like the best 
practice for building metals, or the best practice for agro businesses), and these best practices 
are not limited to documentation. They include tools to automatically create master data, to 
customize, to design models, to apply better processes, etc. 

One of the key SAP success factors is to analyze and apply these available best practices, but 
only in a proper way: it is useless to apply them if there is no one with the sufficient business 
knowledge to apply them properly, and it's a mistake to apply them only because they have an 
industry-specific aspect that you assume is useful for your company. These best practice tools 
are really useful, and I have seen very important savings in time and resources because of their 
usage, but I have also seen how these solutions can miss real needs of companies which 
assumed their importance before analyzing what kinds of solutions they truly needed. Today, with 
the initiatives in the SMB 3 sector, SAP has developed, in conjunction with experienced partners, 
micro-vertical solutions for very specific industries, which can surely also be used as a base for 
big implementations in larger companies. For smaller companies these are tools that allow 
access to world-class solutions without the need of a too expensive investment. For bigger 
companies, these solutions can be a base to access better practices and to make savings in the 
implementations or improvements of their systems. 


Table 1: Best Practices Available Today (02/2004) 


Cross-Industry Best Practices 

Vertical Industry Best Practices 

Business Intelligence 

Automotive 

Enterprise Portal 

Fabricated Metals 

Supply Chain Management 

Fast Moving Consumer Goods 

Customer Relationship Management 

High Tech 

Supplier Relationship Management (*) 

Industrial Machinery & Components 

Product Lifecycle Management (*) 

Pharmaceuticals 

Human Resources (*) 

Retail 

Accounting Germany (*) 

Service Industry 

Online Store (*) 

Wholesale 


Mill Products (*) 


Mining (*) 


Source: www.sap.com and service.sap.com (*) Non-Building Block Versions 


3 SMB: Small and medium business. In different areas and countries of the world, SAP has different 
definitions of this market. The definitions are mainly related to revenue. 
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Knowledge Transfer 

Before the implementation of SAP solutions, you can define your policy about how much you're 
going to depend on external consultants and to what degree, and how you want to handle the 
post go-live support, help desk, and maintenance. All these decisions directly affect how, and to 
what extent, you will need the consultants to make the knowledge transfer to your internal team. 
Some companies decide that consultants will do all the system maintenance; others don’t want a 
dependency on consultants at all. There is surely an intermediate solution between these two 
extremes. The following facts must be understood before making decisions about this issue: 

1 ) During the implementation process of SAP solutions, employees from the organizations 
involved in the project become much more valuable on the job market. Many understand this 
in advance and look for this opportunity to raise their income (understandably) but remain 
with the company for the long-term. Others only use the project to get trained and after that 
look to move on to more lucrative opportunities. 

2) After implementation, you will need assistance to maintain the SAP solutions. Every change 
to the organization (mergers, acquisitions, diversifications, change management, structure 
changes) and to the economic environment (government, globalization, economic situations, 
and taxes) affects your internal needs, and the SAP solutions must be adapted to incorporate 
these changes. You will need either an internal team with special knowledge of these 
changes, or you'll need to select a couple of consultants who can be called in for any urgent 
situation or change needed. 

3) The need for assistance after go-live is not going to be very high if the implementation has 
been successful. But if you have a plan for implementing new functionality, this cannot be 
done with internal teams only, as they will not be qualified. And you may not be able to count 
on the internal team as much as you'd like, because as we said, if the internal team is 
overqualified or is trained too much, sooner or later they will leave the company because they 
lack challenges. 

Change Management 

Every implementation process of SAP solutions can (and, in my point of view, should) take 
advantage of change management and process improvement. This does not mean every 
company should pay a lot of money for this service. Change management is normally implicit in 
the service delivered by good consultants and can be done very deeply or very simply, depending 
on the scope of the implementation and the sophistication of the users. SAP's long history of 
developing enterprise solutions, along with the high number of implementations in the world 
today, have helped develop best practices that include a lot of tools and better ways of doing 
things inside a company. 

I am not going to make a deep analysis of this theme, as it can take a whole book to address 
change management properly. I only want to state, it is very important to take these issues into 
account when defining the scope of SAP implementations, as they can push a project over- 
budget because of a too-deep impact on the organization and the need to administer these 
changes. 
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Avoiding Custom Development 

If you have had any contact with SAP solutions, you have very likely heard the following 
recommendations for SAP development, but they bear repeating: don’t change the standard code 
or develop additional functionality. I have seen many mistakes made around these issues; there 
are still people and organizations that continue to make costly mistakes on these issues. SAP 
solutions are standard solutions with a very high level of parameters that allow for the configuring 
of lots of different scenarios and possibilities. Of course, there are always a few cases where SAP 
cannot be modeled for a company, and in those cases, custom development might be necessary. 
But most of the time, custom developments are made due to a lack of business flexibility on the 
part of the company, or because of a lack of knowledge of SAP solutions on the part of the 
implementation or maintenance team. And some companies are just used to developing 
programs around SAP solutions. I am not saying that SAP programmers are not needed, or that 
developments are 100% avoidable in all cases; but I do say that most of them are avoidable. 

The most needed and justified developments are related to forms, interfaces, and reports, but 
even in these cases, there are lots of tools and report generators that can help, not the least of 
which is the Business Warehouse. BW has become a very robust and customizable source of 
SAP reporting and it is tied into virtually all SAP and mySAP products. Since other options are 
almost always available, and because your SAP customizations are not guaranteed to survive a 
system upgrade, nearly all changes to the standard code or development of additional 
functionality should be avoided. If you do not believe these words 100%, you will remember them 
when you try to migrate a customized SAP system to a newer version. . 

Taking Advantage of Proprietary SAP Tools 

During SAP projects, there are several tools that are forgotten or not very well known, but which 
can help you create better custom solutions that you can take advantage of. In many cases, 
these tools help to avoid generating new proprietary code. A too-high percentage of consultants 
does not know all of these tools, or does not use them because of lack of knowledge or because 
of some myths or false assumptions about them. Without going into a deep and detailed analysis, 

I will mention some of the most important tools you should consider for your project: 

Reporting: 

• Report Writer, Report Painter, and ABAP-Queries, the three report generators available in 
R/3, very powerful, and relatively easy to use. 

• Business Warehouse, the data warehousing tool included in the SAP licenses: highly 
configurable and with easy data-extraction functionalities to all other SAP solutions and 
integration with almost all standard architectures (Crystal, Ascential). 

• Information Systems, the standard reporting structures in some SAP solutions (R/3). 

• ABAP List Viewer, a set of ABAP-Objects available to develop highly configurable reports 
(lots of standard SAP reports are developed with these objects). 

• iViews/MiniApps, standard solutions which include standard SAP data, graphics, and 
transactions into a browser environment (mySAP Workplace/mySAP Portal). 
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Interfaces: 

• BAPIs (Business Applications Programming Interfaces), a set of standard RFCs (Remote 
Function Calls) to access and enter SAP data without the typical maintenance problems of 
custom developments (SAP maintains these BAPIs). 

• IDOCs, the EDI objects for connecting on-line with other systems/solutions. 

• DCOM Connector, a development kit to simplify the development of interfaces to SAP 
solutions from COM+ applications. 

• SAPGUI Off-line entry tools, a set of different tools to enter or access SAP data with standard 
tools like the Microsoft Office Suite. 

• SAP Console, a small server to convert graphic screens from SAP into text screens (typically 
used to access SAP transactions with a text-enabled wireless device like some barcode 
readers). 

• LSMW, an R/3 transaction for developing interfaces. 


Programming screens and logic: 

• GuiXT, non-proprietary SAP software included in the standard SAPGUI. It provides the ability 
to change the appearance of screens without changing the standard SAP code. (It works on 
the front-end level.) 

• Input Assistance, just like GuiXT. It works on the front-end level, and permits users to change 
some logic of the SAP transactions without changing the standard SAP coding. (It needs an 
additional license from the manufacturer.) 

• SAP Console (already stated above). 

• BAPIs (already stated above). 

• SAPGUI Off-line entry tools. 

• User-Exits, predefined places in the SAP code where some proprietary code can be included. 
(SAP guarantees to maintain this code for subsequent versions without alteration of the 
logic.) 

• Field-Exits, a possibility to include some code to control or change the content of input fields. 

• match codes, a way to add or change available filters and queries to search for the content of 
particular fields. 

• Workflow/Webflow, the workflow functionality found across every solution/module of SAP, to 
trigger automatic events when a specific situation occurs. 

• validations and substitutions, customizing tools to avoid codification of controls and 
substitutions of fields found in some areas/modules of SAP Solutions. 

• iViews/Miniapps (already stated above under Reporting). 


Forms: 

SAPScript and SAPForms, two different tools to develop output forms and to avoid using ABAP 
code. SAPForms is much more user friendly and the new (and recommended) tool to be used. 
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Today, with the new NetWeaver™ technology, there are additional tools that should be analyzed: 

• XI (Exchange Infrastructure - The EAI Solution of SAP). 

• SAP Enterprise Portal for e-collaboration, knowledge management, etc. 

• MDM (Master Data Management to ensure information integrity and harmonization 
across the business network). 

• SAP Web AS (Web Application Server for Web services). 

Post-Go Live Tips 

Many times, I listen to people who are afraid of the maintenance and running costs for SAP 
systems; this is a philosophical fear, not necessarily related to the actual costs of SAP solutions. 
The reality is the following: if you see your company as static, then you can have a system 
without any running costs. (Of course, this will tie you to the original system you implemented and 
reflects a policy where Information Technology is not integrated with the company's changing 
business models.) I do not share this point of view and think it is clearly a mistake, even more so 
if you understand the business world we are living in. Information Technology is more and more a 
main issue that any company must address properly to survive. If, on the other hand, you think 
your company is always changing and must be flexible enough to adapt rapidly to market shifts, 
then you have to prepare the company for that. This is not only a matter of paying the SAP fee for 
maintenance or having an internal team for maintenance; this is about continually adapting your 
business strategy and verifying how to accomplish your goals. 

The first thing is to understand what the business plan is and where the company intends to be in 
a medium to long-term timeframe. It's important to clearly understand what tools or solutions the 
company will need and to develop a system and solution plan that fits those needs. This will 
make it clear whether new modules must be implemented, or if new functionalities/solutions will 
be needed. 

As a second point, there should be a clear statement about the policies regarding model changes 
or development of new functionality or reports. If the internal teams do not receive clear 
objectives about this, they will develop an idea about what they think is best and different people 
can have different points of view about these issues. You also have to take into account that 
someone who has not had a lot of work as an internal team member can generate himself a task 
list with user requirements without thinking about the big picture. There are companies whose 
strategy is “no developments out of the standard SAP functionality,” while others “allow any 
development for pleasing the individual important end-users.” The first one is much cheaper, but 
means you have to adapt the company’s needs to the available tools and functionality. There is 
obviously an intermediate point, but that is where the gray zones appear and where difficulties 
can arise if there are no clear policies and statements. 

The third point to take into account is the policy about staying up to date with the new versions 
and functionality. This is also a clear financial issue here, and only a careful analysis will tell what 
efforts make more sense: to investigate new functionalities and improvements in the new 
versions in order to decide when or how to migrate (important with the new Basis technology 
available in the last versions of the SAP solutions), or to concentrate on investigating more deeply 
the functional possibilities of the current version the company has implemented. All these things 
can be done in a cheaper or more expensive way, but you have to have clear policies and goals. 
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Every policy and strategy has its risks and opportunities, and they should be analyzed and known 
if you don't want surprises. 

Documentation 

There are a couple of tools and methodologies used to document SAP models and training 
material. The best-known are those related to the ARIS Toolset and the ASAP methodology. 
These tools are very powerful, but it takes time to develop and maintain the documents 
generated. Not all organizations are willing to pay for this service. What is sure is that 
documentation done in the right way helps organizations to save money. 

If you have no documentation or do not maintain it, you get too dependent on your consultants 
and you'll have real problems, and it will be expensive to replace them. In terms of documenting 
the model, the graphic representation of it is much more important than a written BBP (Business 
Blue Print) itself. I have seen perfectly defined BBPs that were not read by those who should 
have read them, or were not understood by the consultants assessing the project. The best 
projects I have seen were the ones with big pictures explaining and drawing the relationships 
among objects, organizational structures, and processes. There should be big displays of these 
graphics in every key user’s office. 

A relatively new tool to help with the documentation of end-user manuals is the SAP Tutor, a new 
version of the former iTutor. SAP Tutor helps to make electronic-interactive manuals, permits the 
evaluation of end users, and helps companies to understand how they should be better trained. 
This tool is becoming easier and easier to use and its usage is worth analyzing. It is surely an 
effort to rewrite/remake the complete set of end-user manuals, but it really will help later to have a 
good method for training people without formal courses. 

There is a lot of other documentation included in the SAP methodologies that can be generated 
during projects or maintenance. My point of view is very simple: if you do not analyze the future 
usage of the documentation, you will probably invest a lot of effort and money in documents with 
no use. Basic documentation is essential for any stage of an SAP implementation, but the amount 
and depth needed depends on the size of the project and the company, on the policy about it, 
and of the formal need for it (for example, because of quality standards like ISO). 
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Most Common Mistakes in SAP Solutions Lifecycle 

During my experience in the SAP world, I have seen many different scenarios, companies, and 
philosophies for SAP implementations. One thing is essential and I think applicable not only to 
SAP but to all world-class IT solutions (including best of breed or standard solutions): you can 
choose between internal development or the implementation of a solution from a specialized 
vendor. If you do the latter, you have to accept that this is a strategic decision and it's best to stick 
with that. That means that you should avoid combining custom development and outside vendor 
products in the same initiative. Making big developments on a vendor's solution is one of the 
biggest mistakes you can make. With SAP solutions, this point is 100% applicable. 

As I noted earlier, I am not speaking about the maintenance team, or the development of reports 
and interfaces, or changing the parameters of the systems; I am speaking about changing the 
standard coding, creating complex additional functionality, or trying to develop functionality to 
adapt the solutions to the problems, thereby avoiding the better approach of trying to solve the 
problems with the available solutions, tools, and functionalities. Beyond this key point, I want to 
elaborate on some additional things I have seen as common errors during any stage of the SAP 
solutions lifecycle. This enumeration is generic and not specifically applicable to one kind of stage 
or project (implementation, migration, roll-outs, functionality enlargement, etc.). I will write about 
specific kinds of projects in subsequent articles: 

1) Not Using a Good Solution Map. You have to know where your business is going to and 
what your company will need in the future. Definitions made at an early stage of an 
implementation without taking into account the implementation of future functionality are often 
very expensive in resources, effort, and time during improvements or implementation of new 
functionality. In too many of these cases, SAP solutions are charged with the guilt, when the 
real mistake is found in a wrong definition of the model. A good solution map helps with the 
current situation and the planned future improvements, and it helps avoid costly mistakes 
down the line. 

2) Paying more attention to SAP tools than the underlying business processes. SAP 

solutions are tools, not the final objective of the companies implementing them. The business 
processes are always more important than the tools. The tools should be accelerators and a 
help to make the processes more efficient. Not all consultants understand things this way. 
Most problems appear when you have a senior “SAP implementer” who knows every 
technical trick, functionality, and tool inside the SAP solutions, but does not understand the 
business processes or their implications. These consultants constantly apply technical 
solutions that, even if theoretically right, are very often not useful because of extra technical 
issues (volume of data, volume of transaction, cost-benefit of the solution, cultural issues, 
human resources, etc.). 

3) Emphasizing outside consultants instead of building a strong internal team. A common 
mistake made by new SAP consultants is to think that the knowledge of the systems makes 
them more intelligent (or at least more valuable) than the people of the business they are 
working with. Good “SAP Business consultants” are people who try to hear and understand 
the internal team, even if they already have experience in implementing SAP in that particular 
vertical industry. If the company itself does not decide about the functionalities to be used 
and if they don't take ownership of the SAP Business model, the model will not be very useful 
and no one inside the company will assume responsibility for its success and maintenance. 
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4) Investing in costly development instead of working with SAP's own solutions. Many 
ABAP programmers nowadays keep their jobs thanks to the lack of research on the 
possibilities of SAP solutions and its customization. There are also many cases where junior 
consultants pass the problems to programmers because anything can be done with code. It is 
only a matter of investment. The companies learn these mistakes the hard way: they realize it 
is dangerous to develop or change too much code when they migrate or when they 
implement new or different functionality and have to integrate it into the developments. I have 
seen several cases during migrations where the developments could have been replaced 
with standard functionality or reports, or even by customizing the original version of the SAP 
solution without using ABAP. 

5) Paying for programmers instead of using existing reporting tools, and lacking 
knowledge of the tools that are available for custom reporting. After realizing it is 
impossible to solve processes or information needs with standard reports, the tempting way 
to solve these problems is to pass them directly on to programmers, even before analyzing 
the usage of code generators, report generators, ABAP Objects, or interface generators like 
the ABAP-Query. There are a number of useful reporting tools that SAP users are not always 
familiar with, including Report Writer, Report Painter, ABAP List Viewer, substitutions or 
validations, and many other tools like them (including tools developed by other programmers 
and third-party vendors). Even many ABAP programmers do not know how to use these 
workbench tools and, instead, opt to directly generate a new code. On top of this very few 
functional consultants have deep knowledge of the data dictionary. 

The lack of experience with SAP reporting tools leads to a range of problems. In some 
situations, these reporting tools aren't used at all, or when they are used, they generate 
reports that consume too many resources and are not useful due to performance reasons. It 
is a mistake to think these tools are not good. The mistake lies on the bad usage of such 
tools. If the programmers (who normally have a good knowledge of the data dictionary and 
database normalization) learn to use the tools to develop better and more standard solutions, 
this will result in savings and better solutions. These tools cannot solve all problems and it 
must be decided which one to use and when, but this can only be done if the “SAP techies” 
know these tools better than they often do. 

6) Assuming that SAP is too expensive because of hardware costs, and buying 
expensive best-of-breed software to supplement SAP when SAP's own product line 
has a similar (and cheaper) solution. In the past, when hardware was very expensive for 
the implementation of SAP solutions, there where solutions and functionality which were 
nearly prohibitive for some companies. However, hardware is getting more and more 
accessible, even more for small implementations. There are also new technologies that can 
combine SAP solutions in one server for small implementations, without the need for new 
hardware. Best practices, free operative systems, and free databases help to make 
accessible more SAP solutions to a wider range of companies. It is a mistake to think it is not 
worth analyzing other SAP solutions beyond the core ERP system that SAP provides. SAP 
has many other quality applications, such as BW, SEM, and CRM, that can be much more 
cost effective than custom development or third-party solutions. 

Looking Ahead: New Trends, Technologies, and Tools 

The SAP world is changing very quickly. For lots of consultants, clients, and people who use SAP 
every day at work, these changes are not so obvious. Many internal consultants in companies 
using SAP still have the perception that SAP solutions are systems like early developments in the 
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computer industry. It's important to understand that it is much healthier for companies to 
continuously investigate the latest SAP trends, functionality, and tools and make a commitment to 
maintaining the company on the latest versions of SAP. It is easier and cheaper to do this if it's 
done in a conscious and planned way. 

Today all people related into SAP solutions in any way should know concepts like these: 

• ASAP 4 

• Global ASAP 5 

• SAP-Business One 

• mySAP-AII-ln-One 

• mySAP-Business Suite 

• Best Practices 

• BC-Sets 6 

• BB 7 

• CATTs 8 

• Workflow 

• SAP T utor 9 

• BW 10 

• SEM 

• SAP NetWeaver 11 
. XI 12 

• 1-Docs 



4 ASAP: The project management methodology and tool developed by SAP with accelerators that help to 
improve project duration 

5 Global ASAP: The project management methodology and tool developed by SAP for global models and 
rollouts. 

6 Business Configuration Sets: A new tool which helps to make roll-outs easier, standardize configuration, 
prepare vertical solutions, replicate models to different objects, etc. 

7 Building Blocks: Tools for documenting and saving implementation, configuration, and installation data 
of process definitions and technical solutions, used to build replicable and micro-vertical solutions. 

8 CATT: Computer Aided Test Tool: More than only a test tool, it is used for many functions, even to 
create standard data sets for demonstration purposes, for importation of master data that is part of a 
standard model for roll-outs, etc. 

9 SAP Tutor (once the iTutor): An easy-to-use SAP tool to prepare interactive manuals for training, testing, 
and documenting purposes 

10 BW: Business Warehouse. The data warehousing solution included in the SAP Solutions 

11 SAP NetWeaver: the new SAP technology architecture to address the new trend SAP is calling 
“Adaptive Computing Infrastructure” 

12 XI: Exchange Infrastructure. This is the SAP Solution for Enterprise Application Integration 
functionalities. 
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• BAPIs 13 

• Archiving tools 

• Report Generators 

• Web AS 14 
. LE 15 

• Advanced TR 16 

• SAP Service Marketplace 17 

• Microverticals 

• Industry Solutions 

• MDM 18 

• Portals 

• Workplace 

• APO 19 

• SCM 20 

• FSCM 21 

• SRM 22 
. PLM 23 

Do you know what all of these terms mean, how deep the functionality goes, and what everything 
is used for, or have you simply heard about them without knowing the details? Some of these 
terms are commercial concepts, others are generic concepts, others are tools, others are 
products, but all of them have implications for you and your company that are worth investigating, 
at least for an overview. In future publications I will try to give an overview of every concept I think 
will be important for you as a project manager or as someone responsible for SAP solutions to 


13 BAPI: Business Application Programming Interface: a standardized RFC (remote function call) which 
guarantees upwards compatibility for interfaces 

14 Web AS: Web Application Server. It is integrated to nearly all of the latest versions of the SAP products. 
It is in R/3 from version 4.7 Enterprise upwards. It is also available as a standalone server. 

15 LE: Logistic Execution. A relatively new module of R/3 that integrates transport planning and costing 
functionality for the purchasing and delivery departments. 

16 Advanced TR: Advanced treasury. Functionality for companies working with complex investments. 

17 SAP Service Marketplace: the service portal for customers and partners of SAP where all the players 
meet and search and share important information on developments, patches, products, and functionality. 

18 MDM: Master Data Management. A solution to standardize and normalize master data inside and cross 
applications 

19 APO: Advanced Planner and Optimizer - SAP's Advanced Planning and Scheduling product, the core 
solution of SAP's Supply Chain Management (SCM) suite. 

20 SCM: Supply Chain Management 

21 FSCM: Financial Supply Chain Management 

22 SRM: Supplier Relationship Management 

23 PLM: Product Lifecycle Management 
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keep up-to-date on. As we know, in the SAP and the IT World, these concepts will evolve and 
new ones will be created continuously. 

Conclusion 

Current trends indicate that initial SAP projects now last no longer than nine months, and most of 
them are shorter. (Even for big corporations, it is much healthier to make core models and 
smaller rollouts, with partial success stories, rather than try for one long big bang.) Additionally, 
SAP best practices are no longer just concepts; there are vertical configurations, documentation, 
and tools to apply them in an easy and successful way. From my point of view, the BC-Sets and 
Building Blocks are the future (for new implementations and roll outs). Nearly all companies 
understand that “SAP Business Consultants” (as described in the appendix to this article) are the 
most effective consultants. Even if they are more expensive per day, the results are clearly better 
with these kinds of consultants, at least in terms of leading the projects or maintaining SAP 
Solutions. 

With all the themes and experiences shared in this article, I wanted to make clear which things 
should be taken into account to have success in any kind or size of implementation. Please take 
or leave what you think is most important for your job or organization. It is really easy, as long as 
you have the experience to do it, or if you find the right person or group of persons to help you in 
this process. SAP solutions are not a mystery any more, and there are many good “SAP 
Business Consultants” in the world who make the process easier and can help your company to 
grow and become more profitable. There are also more “SAP Implementors” who know SAP 
products very well. They are familiar with its customizing possibilities and can help to implement 
them in a proper way. Better tools and best practices have gone a long way to simplifying SAP 
implementations and offering a better return on investment to SAP users. I look forward to 
elaborating on some of the best innovations and products in future articles. 


Tomas Fertig, BDO Consulting. Tomas is a director of a regional SAP service partner. He is 
certified in R/3 MM, ASAP, ABAP, and Workflow. He has more than 15 years of overall IT 
Consulting experience and more than 8 years working with SAP solutions. He acts as the 
technical leader of the company and coach of SAP Business Consultants and SAP leaders. 
Tomas has spent the last 8 years working with SAP solutions, first as a consultant and 
programmer, then as leader, coach, pre-sales consultant, trainer, and solution developer. He 
participated in different ways in more than 20 different SAP projects in different countries and 
environments. He is fluent in four languages (English, German, Spanish and Portuguese) and is 
currently developing his career in Mexico City. Tomas' email address is tfertig@fibertel.com.ar. 
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Appendix: The Different Types of SAP Consultants and How They Affect Project Success 

For a better understanding of the risks and mistakes that impact SAP implementations, I want to 
explain in a very simple way how I visualize, name, and classify SAP consultants nowadays, 
defining in general an SAP Consultant as a person who helps implement, maintain, migrate, 
expand, install, or customize any SAP business solution. In the SAP world, I see four different 
types of consultants 24 : 

1) “SAP Techies”: I am not going to speak a lot about them as I think they don’t really manage 
projects or implementations, and as such, are rarely the reason for a mistake. Typically, SAP 
Techies are programmers, ABAP specialists, Basis specialists, or software architects 
specializing in SAP solutions. Sometimes they are used as the “tool” that causes project 
mistakes, but this is mainly because of the wrong decision on the part of their managers. 
These folks are always needed in any stage of SAP projects or implementations. The real 
secret is to have a good plan to utilize them effectively. 

2) “SAP Implementors”: These are the most frequently found “consultants” in the SAP world 
(and for my part, I do not consider them the best SAP consultants). These consultants know 
the product very well and understand most of the flags and parameters. They can very easily 
solve technical problems and set parameters on very complex problems, but they are 
typically very much oriented to specific modules and limited functionality. They do not tend to 
see the integration and overall process importance of an SAP solution. These narrow-view 
consultants typically came from being programmers or analysts, or else have been certified 
after obtaining a degree but before gaining practical experience in business. They are useful 
in large projects with a good number of consultants, where the process definitions or the 
development of the Business Blueprint are taken on by “SAP Business Consultants” or in 
conjunction with “SAP Process Consultants”. 

3) “SAP Process Consultants”: These consultants typically have very good knowledge of the 
processes and the problems of the real job. Most of them are people from the company 
installing SAP, and so they don't usually have a deep knowledge of information systems. 
They may have participated internally in an SAP Project, but they do not have a very deep 
knowledge of technical issues or they don’t tend to like computers or technical themes. You 
find these folks in companies as key "super" users or internal consultants, and they often 
need continuous assistance from “SAP Implementors” or “SAP Business Consultants”. They 
are essential in new implementations to transmit the history, reality, and plans for the future 
of the company where the project is taking place. If you extrapolate these consultants to the 
early non-IT World, they can be compared to the Process Reengineering Consultants. 

4) “SAP Business Consultants”: In my view, these are the most complete SAP consultants. A 
cross between Implementors and Process Consultants, they understand very well the 
underlying business processes and can give some advice on best business practices. They 
are not the best technicians, but they can solve any technical problem because they 
understand the SAP philosophy. They are able to work effectively with technical teams to 
address functionality gaps and customize SAP solutions. They can discuss technical issues 
because they have a clear understanding of the depths of SAP's functionality and can easily 


“ 4 All these types of consultants are probably found in any kind of IT-Consulting and you can extrapolate 
the types to any Solution or ERP. I am referencing mainly the profiles found in the SAP world, their 
application, and risks. A deeper definition and my view of these consultants are described better in the book 
I am writing about IT Business Consultants. 
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investigate technical solutions as needed. They always make a cost-benefit analysis of the 
implementation of a tool, functionality, or process, before going to the technical solution. 

As you can see, all these kinds of consultants are important for different jobs, for different kinds of 
projects, and for different kinds of companies. As a general rule, the smaller the company, the 
higher the business complexity, or the longer you are using IT business solutions, the more you 
need the fourth type of Business Consultants. Process Consultants are very important during the 
definition of business models, during the creation of the solution maps or business landscapes, 
and for process reengineering when you use SAP solutions. 


The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned by 
Klee Associates, Inc. 

NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy 
or use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensure 
accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc. 
reserves the right to make changes without prior notice. 

NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG. SAP AG 
software referenced on this site is furnished under license agreements between SAP AG and its customers and can be 
used only within the terms of such agreements. SAP AG and mySAP are registered trademarks of SAP AG. 

All other company and product names used herein may be trademarks or registered trademarks of their respective 
owners. 


Copyright © 2004 by Klee Associates, Inc. 

www.SAPtips.com 


Page 21 



